home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group00a.txt
/
000125_icon-group-sender _Fri May 26 08:35:41 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-01-03
|
4KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA02292
for icon-group-addresses; Fri, 26 May 2000 08:35:31 -0700 (MST)
Message-Id: <200005261535.IAA02292@baskerville.CS.Arizona.EDU>
From: Steve Wampler <swampler@noao.edu>
X-Newsgroups: comp.lang.icon
Subject: Re: CODE() and @/2
Date: Fri, 26 May 2000 07:54:20 -0700
X-Trace: noao.edu 959352862 96002 140.252.38.6 (26 May 2000 14:54:22 GMT)
X-Complaints-To: abuse@noao.edu
X-Accept-Language: en
To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
"F.G. van DORP" wrote:
>
...
> Can somebody please explain the infix @ operator ?
> The closest I can get is something like: @'s first argument gets pushed
> onto its second argument's stack before the latter is activated (and
> at this point my mind goes blank... OK, so the infix is just a prefix
> @ with &NULL as the first argument, which doesn't help me a lot either).
> Its purpose is apparently to have co-expressions communicate between
> themselves (thus enabling them to gang up against the programmer ?)
Think of co-expressions a threads that don't execute simultaneously.
Instead, co-expressions cooperate by explicitly passing control between
them using the @ operator as a "transfer point". Logically, the CPU resource
is being passed among the co-expressions (remember that Icon's execution
starts in a co-expression, referenced by &main).
Now, think of the @ operator from the point of view of the co-expression
that is invoking it - the behavior of the @ is very much like that
co-expression making a function call - execution of the co-expression
(call it "A") is suspended until execution "returns" from the @ - perhaps by
some
other co-expression (call it "B") invoking the first via an @ [think about
that for a moment, it's probably the confusing part!]. If B uses the
infix @ - as in (say) "foo" @ A, then A will see its @ operator as "returning"
the value "foo".
So, each co-expression sees @ as an operator that "invokes" another
co-expression
to produce a result. The result can be produced in one of two ways:
(1) Since a co-expression is an expression, and since all expressions in Icon
produce results, there is an implicit transfer of the result of that
expression back to the invoking co-expression. This is how most people
use co-expressions, as in:
nextLabel := create "L" || seq()
to produce a unique label whenever activated. (Note that this can also
be done using a procedure, as in:
procedure newLabel()
static suffix
initial suffix := 0
return "L" || (suffix +:= 1)
end
but some people find the co-expression form simpler. Also note that
procedure newLabel2()
return "L" || seq()
end
and
procedure newLabel3()
suspend "L" || seq()
end
do *not* perform the same function.)
(2) A co-expression may explicitly return a value to a waiting co-expression
using the binary @ operator. The explicit transfer of control used here
more closely matches the role of coroutines found in some other languages,
and is likely to be used only in situations where coroutines would be used
in those other languages. However, useful situations for applying
coroutines
are few and far between and almost always very complex situations. It is
difficult to find simple examples where using coroutines is cleaner than
alternatives.
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu